Conversation
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
nguyen-andrew
left a comment
There was a problem hiding this comment.
Looks good so far! Just some minor comments and questions
modules/manage/partials/gbac-dp.adoc
Outdated
| @@ -0,0 +1,336 @@ | |||
| // tag::single-source[] | |||
|
|
|||
| Group-based access control (GBAC) builds on xref:manage:security/authorization/rbac.adoc[role-based access control (RBAC)] to simplify permission management at scale. Instead of assigning roles or ACLs to individual users, you assign them to OIDC groups managed by your identity provider (IdP). Users inherit permissions from all groups reported in their OIDC token claims, so onboarding and offboarding require no changes in Redpanda. | |||
There was a problem hiding this comment.
I wonder if we should mention OIDC earlier in the paragraph (like in the first sentence) so readers immediately understand that GBAC depends on OIDC being configured. I think the OIDC dependency could be easy to miss upfront until the reader reads further down (like the Prerequisites section).
modules/manage/partials/gbac-dp.adoc
Outdated
| Users with more than 200 group memberships in Azure AD receive a URL reference in their token instead of a list of group names. Redpanda does not follow that URL and cannot resolve groups in this case. Mitigation: filter token claims to include only the groups relevant to Redpanda. | ||
|
|
||
| Nested groups:: | ||
| Redpanda does not recursively resolve nested group hierarchies. If group A contains group B, only the direct memberships reported in the token are used. Use `nested_group_behavior: suffix` to extract the last path segment from hierarchical group names when needed. |
There was a problem hiding this comment.
Adding a link to Customize token claim extraction#nested_group_behavior or the nested_group_behavior section in the cluster properties reference could be helpful here too, if possible.
modules/manage/pages/kubernetes/security/authorization/k-gbac.adoc
Outdated
Show resolved
Hide resolved
treevon
left a comment
There was a problem hiding this comment.
This looks good. The token extraction section is really nice with clear examples
modules/manage/partials/gbac-dp.adoc
Outdated
| == Prerequisites | ||
|
|
||
| * xref:manage:security/authentication.adoc#oidc[OIDC authentication] must be configured and enabled on your cluster. | ||
| * Superuser access to configure cluster properties and manage ACLs. |
There was a problem hiding this comment.
nit - this is a prerequisite to enable OIDC, so should appear first
There was a problem hiding this comment.
@treevon for Cloud should we just remove this superuser prereq?
There was a problem hiding this comment.
@treevon since we don't have superuser in Cloud, can we remove (conditionalize this out) for Cloud?
There was a problem hiding this comment.
@kbatuigas would you please conditionalize this out for Cloud docs?
There was a problem hiding this comment.
Moved superuser prereq into conditional
modules/manage/partials/gbac-dp.adoc
Outdated
| --resource-pattern-type prefixed | ||
| ---- | ||
|
|
||
| If your groups use path-style names (with xref:reference:properties/cluster-properties.adoc#nested_group_behavior[`nested_group_behavior`] set to `none`), use the full path as the principal name: |
There was a problem hiding this comment.
I think we should move this to the section on claim extraction
# Conflicts: # modules/get-started/pages/release-notes/redpanda.adoc
graham-rp
left a comment
There was a problem hiding this comment.
We ended up removing the --group flags on rpk security role
modules/manage/partials/gbac-dp.adoc
Outdated
|
|
||
| [,bash] | ||
| ---- | ||
| rpk security role assign <role-name> --group <group-name> |
There was a problem hiding this comment.
We ended up pivoting to using ACLs directly in rpk. This gets rid of --group in favor of the principal directly, so rpk security role assign <role-name> --principal Group:<group-name>
| .Authorization matched on a group ACL | ||
| [%collapsible] | ||
| ==== | ||
| This example shows an API Activity event (6003) where the authorization decision matched an ALLOW ACL on a `Group:` principal. The `actor.user.groups` field includes the matched group with type `idp_group`, and the `authorization_metadata` shows the group ACL that granted access. See xref:manage:security/authorization/gbac.adoc[]. |
There was a problem hiding this comment.
| This example shows an API Activity event (6003) where the authorization decision matched an ALLOW ACL on a `Group:` principal. The `actor.user.groups` field includes the matched group with type `idp_group`, and the `authorization_metadata` shows the group ACL that granted access. See xref:manage:security/authorization/gbac.adoc[]. | |
| This example shows an API Activity (6003) where the authorization decision matched an ALLOW ACL on a `Group:` principal. The `actor.user.groups` field includes the matched group with type `idp_group`, and the `authorization_metadata` shows the group ACL that granted access. See xref:manage:security/authorization/gbac.adoc[]. |
modules/manage/partials/gbac-dp.adoc
Outdated
| + | ||
| -- | ||
| . From *Security* on the left navigation menu, select the *Groups* tab. | ||
| . |
There was a problem hiding this comment.
@kbatuigas reminder about these steps. We can update later if necessary
| @@ -0,0 +1,13 @@ | |||
| To create an ACL for an OIDC group in {ui}: | |||
There was a problem hiding this comment.
Style suggestion: The section is titled "Create group-based ACLs" but the steps navigate to the Roles tab. The NOTE explaining why ("{ui} assigns ACLs through roles") comes after the procedure on line 13, which may confuse users who expect to land on an ACL-related page.
Consider adding a brief lead-in sentence before the numbered steps:
In {ui}, group-based ACLs are managed through roles. To create an ACL for an OIDC group:
The NOTE at the end can stay as supplementary detail.
|
Style suggestion — "Authentication grants permission to interact with Redpanda resources" conflates authentication with authorization. Authentication verifies identity, not permissions. Suggest: |
|
Is GBAC an enterprise only feature? if so, we should call that out and add to Enterprise features list. |
@david-yu Yes -- I have a pending commit to https://deploy-preview-1584--redpanda-docs-preview.netlify.app/current/get-started/licensing/overview/#self-managed, but I have not yet received confirmation on what the behavior is when the license expires. |
@nguyen-andrew or @treevon Could you confirm the behavior upon license expiry? This is what i got from Claude so far |
@nguyen-andrew @treevon @david-yu This PR must be merged tonight in order for us to prep the release PR tomorrow. I'll do that now, but I posted in the #gbac channel in Slack so I can check for a response there, or try and add a quick doc update tomorrow. cc @JakeSCahill if we get confirmation on the license expiry tomorrow, could we still add that in to the release PR before you have to merge it? |
Adds enterprise license requirement banner to the Group controller documentation as GBAC (Group-Based Access Control) is an enterprise feature that requires OIDC authentication. Addresses PR feedback from david-yu requesting the license banner based on the pattern established in PR redpanda-data#1584. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Description
Related PR to add Security to Admin API v2: redpanda-data/api-docs#60
Single sourcing to Cloud: redpanda-data/cloud-docs#536
This pull request introduces comprehensive documentation for Group-Based Access Control (GBAC) in Redpanda, detailing how permissions can now be assigned to OIDC groups in addition to individual users. It adds new conceptual and how-to guides, updates navigation, and describes configuration, usage patterns, and limitations for GBAC. It also documents new configuration properties relevant to group extraction from authentication tokens.
The most important changes are:
GBAC Documentation and How-to Guides:
gbac.adocunder security/authorization, with detailed instructions, usage patterns, configuration, and examples for assigning groups to roles and creating group-based ACLs. [1] [2]gbac-assign-group-role.adoc) and group ACL creation (gbac-create-group-acl.adoc). [1] [2]Navigation and Discoverability:
nav.adoc) to include GBAC under both Kubernetes and general security/authorization sections, making the new documentation easily discoverable. [1] [2]Release Notes and Feature Announcements:
nested_group_behaviorandoidc_group_claim_path.OIDC Authentication Documentation:
Resolves DOC-1789
Review deadline: March 3rd
Page previews
Main doc - GBAC
Cluster Properties:
Authorization index
Audit logging
Audit logging samples
What's new
Checks